A controller area network (CAN) standard defines a message-based protocol that can be utilized to transmit and receive messages between multiple controllers over a shared bus. This technology is widely utilized in the automotive and aerospace industries to transmit messages through vehicles and airplanes, for example, communicating sensory input or device states between various controllers over the bus.
Controllers with messages to send can arbitrate utilization of the bus based on an identification field in the messages, as a value in the identification field can both identify the message and indicate a priority of the message. When controllers have messages to transmit on the bus, each of them can begin transmitting their corresponding message on the bus during a same transmission period and listen to the bus to determine whether the identification field of their message was overwritten by a message from a competing controller. If the identification field of their message was not overwritten, the controller has control over the bus and can continue to transmit the message. When the identification field of their message is overwritten, however, the controller loses bus arbitration to another controller with a dominant priority annunciated by the identification field in the message.
Each controller typically includes at least one queue or other storage buffer to order messages awaiting transmission over the bus. The controllers can order messages awaiting transmission with any number of schemes, for example, the ordering can be based on message priority in the identification field, arrival time at the controller, a transmission period, a retransmission interval defined for the message, a combination of thereof, or the like. Thus, a message awaiting transmission over the bus contends with competing messages locally in the controller as well as with messages in other controllers attempting to utilize the bus.
Since controller area networks typically include many controllers, each of which can relay messages from multiple sensors, actuators, and/or control devices, they are often designed, tested, and verified in software prior to implementation. After generation of a design for a controller area network, software and hardware “tools” can attempt to verify the design, for example, by confirming interconnections between components in the controller area network, determining timing latencies for different messages in the design, etc. The results of the verification process can be utilized to confirm the design operates within a specification, correct errors in the design, or otherwise improve the design.
One of the timing latency metrics that can be determined during the verification process is worst-case latency for a message, which can identify a longest time the message can take to be delivered through the controller area network. Traditionally, the software and hardware “tools” utilize deadline monotonic analysis (DMA) to determine the worst-case latency for a message. Deadline monotonic analysis, however, assumes that each controller provides messages to the bus in priority-order, i.e., without priority inversion within the controller itself. Since many types of controllers utilize ordering schemes that do not provide messages to the bus in priority-order, traditional “tools” often succumb to using probabilistic methods to predict the worst-case latency with a “good enough” confidence level. Understanding the limits to traditional worst-case latency analysis, many designers of controller area networks build their designs with a fair amount of cushioning in order to accommodate the lack of precision available in conventional calculations of the worst-case message latency, for example, by self-limiting bus load to a lower level than available or implementing redundant transmission of high-priority messages.